The packaging density of LSIs has been increased with the advance of process technology. This greater chip density has made it possible to integrate a system that used to be implemented at the board-level into a single chip as a system LSI. The variety of functional modules included in a chip and the scale of circuitry has also increased. Along with this increase has come widespread replacement of conventional designs using hardware description languages such as Verilog-HDL and VHDL by designs in system description languages such as System C and Spec C.
Examples of well-known design support tools using system description languages include CoCentric from Synopsys and ConvergenSC from CoWare. System LSI can be designed by inputting modules written in a system description language on a block diagram input screen.
Once the design of the system LSI is completed, a simulation model can be generated from the design support tool, a simulator is activated to perform simulation to check the functions and performance of the designed system LSI. That is, before building an actual hardware system, a simulation of the system is performed to evaluate the system, thereby avoiding defects or performance deficiencies.
The following three levels of module descriptions in the system description languages are known.
Transaction Level (TL):
At this abstraction level, bus communications between modules are modeled to describe functions. Because this level functions based on the start and end times of communications and on communication data, the clock-by-clock accuracy is low. Because functions are simulated based on events, the simulation speed is very high. The transaction level is suitable for evaluating the entire system because operations of the system agree with operations of actual hardware.
According to the definition by ARM Limited, the transaction level is subdivided and corresponds to PV (programmer's view), PVT (programmers view+timing), and CL (cycle level).
Bus Cycle Accurate (BCA):
At this abstraction level, functions are described as input and output events. The system can be accurately simulated at input and output sections.
This level is equivalent to CC (Cycle-Callable) in the definition by ARM Limited.
Register Transfer Level (RTL):
At this abstraction level, circuits are described in terms of synchronous transmissions between register files. Functional behavior can be simulated with considerably high accuracy. Because functions are simulated on a clock-by-clock basis, very fast simulation can be performed.
This level is equivalent to RT (RTL event-driven) in the definition by ARM Limited.
Generally, the higher the abstraction level, the faster the simulation; the lower the abstraction level, the higher the accuracy of simulation.
Simulation models used for simulation of a system are described at transaction level.
Examples of widely know transaction-level simulation models include an AMBA bus released by ARM Limited (AMBA AHB Cycle Level Interface (AHB CLI) Specification, released on Jul. 15, 2003).
FIG. 1 shows bus transactions defined in AHB CLI. The transaction methods listed in FIG. 1 can be mapped to hardware signals specified in the AMBA AHB bus protocol. FIG. 2 shows correspondence among transaction methods, attributes, and hardware signals. As shown in FIG. 2, each attribute and each method itself correspond to at least one hardware signal. The methods can be used to simulate bus behavior.
A method for simulating the behavior of bus will be described with reference to FIGS. 3 and 4. FIG. 3 shows correspondence between the transaction methods and signal waveforms. FIG. 4 is a diagram for explaining simulation using transaction methods.
At time T1, bus master 1 issues a request onto the bus. The bus master 1 calls the method request ( ) and issues it to the bus. This corresponds to assertion of the signal HBUSREQ_M1. The bus causes an arbiter to start arbitration (arbitrate ( )). The bus issues the method response ( ) [OKAY, READY] to the master. This corresponds to the signals HREADY and HRESP.
At time T2, master 2 issues a request (request ( )) onto the bus. This corresponds to assertion of the signal HBUSREQ_M2. At the same time, the bus provides grant to master 1 (arbitrate ( ) [grant M1]). This corresponds to assertion of the signal HGRANT_M1.
At time T3, master 1 detects the grant (has_grant ( ) [TRUE]) and ends the request (end_request ( )). This corresponds to deassertion of the signal HBUSEREQ_M1. Master 1 starts a transaction (set_protection ( ) and init_transaction ( )). These correspond to signals such as HPROTO, HTRANS, HADDR, HABURST, HWRITE, and HSIZE. At the same time, the bus performs address decoding and issues the transaction to a slave (write ( ) [address A1] and control_info [NONSEQ, INCR4]).
During the period from time T4 to time T7, master 1 sends data onto the bus (set_data ( )). This corresponds to the signal HWDATA. Then, the bus transfers the data sent from the master to the slave (set_data ( )).
At time T6, the bus provides grant to master 2 (arbitrate ( ) [grant M2]). At time T7, master 2 detects the grant and starts access to the bus.
In this way, the transaction methods have the same functions as the behavior of hardware signals. It can be seen that the methods and attributes can be mapped to hardware signals.
In AHB CLI, methods for changing the configuration of busses are provided in addition to the transaction methods. These methods can be used to change the address width, data width, address map of a bus.
FIG. 5 shows hardware configuration methods. As shown in FIG. 5, the methods can be categorized as methods that are executed during elaboration for a simulator to read a system model or methods that can be used during simulation. Methods that changes bus configuration while simulation is being executed are initialize_map ( ) for decoder and priority ( ) and set_default_master ( ) for arbiter.
These methods relate to actual hardware operation. The method initialize_map ( ) corresponds to the signal remap and the methods priority ( ) and set_default_master ( ) correspond to register access signals in the arbiter.
Methods used for verification are also provided in the AHB CLI. These methods correspond to backdoor functions commonly used for verification of hardware. They can be used to directly read and write data at a specified address regardless of a bus protocol.
FIG. 6 shows verification methods. Masters use three arguments: address, pointer to data, and transfer size. They relate to hardware. Slaves use four arguments: master ID, address, pointer to data, and transfer size, which also relate to hardware.
However, these conventional techniques involve creation of special monitors for monitoring transactions to verify a system or individual modules. Even for RTL which is a lower abstraction level, a verification monitor must be created. Thus, the conventional techniques have the problem of requiring extra labor for developing monitors.
Furthermore, a monitor itself is typically implemented as a functional module. However, the information that the only function module is holding may be required, to analyze the information regarded as the object of the monitor. For example, although bus model includes the function of an address decoder within it, address map information cannot be obtained by externally observing transactions. In such a case, the monitor and functional modules must share information. However, implementing such a monitor is considerably laborsome.
Moreover, because simulation at transaction level is performed by calling functions, known as methods, of modules, a monitor cannot readily be created. While monitoring methods are provided in the AHB CLI, such methods are not provided in most cases.
Verification methods are defined in the AHB CLI and the like. However, those methods must be called during simulation of actual hardware operation in such a manner the called methods do not affect the results of the simulation. Accordingly, verification using these methods is complex.
Moreover, verification through heavy use of methods increases the number of events during simulation and therefore significantly affects the speed of the simulation, resulting in reduction in simulation speed.
Another method that verifies a system or modules without using methods is known in which information about transactions of each module are dumped as a waveform and the waveform is observed. However, it is almost impossible to verify a vast number of results of system simulation by observing their waveforms. Also, holding waveform information in files requires a large amount of disk memory and it is difficult to perform simulation for a sufficient amount of time.
Determination cannot be made from such comparison as to whether latency in one functional module was caused by contention with another functional module or whether the latency is a minimum latency required by the functional module. Therefore, information obtained from such comparison is insufficient for a designer to analyze the performance of a system and optimize system configuration and processing sequences.
Because of the expanded scale and higher functionality of recent system LDIs, the number of functional modules and buses in a system has been increasing. It is difficult to analyze and verify such complex systems by using the conventional approaches provided above.